Automotive Ethernet Routing in Fat Trees


Ermu Lu (A paper written under the guidance of Prof. Raj Jain) DownloadPDF

Abstract

This is a survey of automotive Ethernet routing in fat trees. Since Ethernet has been the standard technology for Local Area Networks (LANs) for decades, it has played an important role in the development of various communication methods. Over time, a large number of transmission methods and protocols have been developed, implemented, and verified to provide rich functions that run on Ethernet networks. With the continuous increase in the number of automobiles, people's requirements for the functionality and safety of automobiles are also increasing. The Ethernet fat-tree structure should burst into vigor in the future development process.

Keywords

automotive Ethernet, fat trees, protocols, topology

Table of contents

1. Introduction
2. Automotive Ethernet 3. Fat Tree 4. Routing in Fat Trees Protocol 5. Automotive Ethernet Routing in Fat Trees 6. Conclusion
7. References
8. List of Acronyms

1. Introduction

Automotive Ethernet is a new type of local area network technology that connects different automotive electronic devices in the car. An important aspect of automotive Ethernet cost analysis is the topology. The difference in topology will greatly affect the design of current hardware equipment, including wiring harness, transceiver chip, connector, switch, and filter, etc. It will also affect the complexity of the software. The switch is the main factor of network optimization, and it adds the flexibility of constructing the network topology. Therefore it is necessary to carefully consider the position of the switch in the network.

The Routing in Fat Trees (RIFT) protocol addresses the demands of routing in Clos and Fat-Tree networks via a mixture of both link-state and distance-vector techniques colloquially described as 'link-state towards the spine and distance vector towards the leafs' [Kheradpir19] . RIFT requires almost zero necessary configuration making IP fabrics simpler to manage. Extensive tracking and logging capabilities allow scaling advantage for IP fabrics. RIFT has maximum utilization of paths without looping, thereby adding resiliency in the IP fabric. These benefits of RIFT Protocol make RIFT an important part of automotive Ethernet [Ergun21].

In this paper, section 2 explains automotive Ethernet. Section 3 presents fat tree. Section 4 describes routing in fat trees protocol. Section 5 mentions automotive Ethernet routing in fat trees. Finally, section 6 concludes the paper.

2. Automotive Ethernet

Automotive Ethernet is a cost-effective, lightweight option that can deliver data at speeds of 100-150 Mb/s. It's a proven technology that serves the needs for both capacity and integration. Unlike non-automotive Ethernet, automotive Ethernet cables are an unshielded, single twisted pair, designed for lower weight and cost, and pulse amplitude modulation 3-level or pulse amplitude modulation 4-level (PAM3/PAM4) modulation to achieve high data rates and reliability [Kim20] . While Controller Area Network (CAN), Controller Area Network Flexible Data-Rate (CAN-FD), Local Interconnect Network (LIN), and other networks may continue to be relevant shortly, automotive Ethernet can transport data roughly 100 times faster than a CAN bus and is better suited to meeting the needs of future automotive networks.

2.1 Ethernet

Since Ethernet has been the standard technology for local area networks (LANs) for decades, it has played an important role in the development of various communication methods. Over time, a large number of transmission methods and protocols have been developed, implemented, and verified to provide rich functions that run on Ethernet networks.

TCP/IP is a protocol suite that implements Internet connection and application programs. It has been used on Ethernet from the beginning, bringing basic functions such as e-mail, World Wide Web access, file transfer, and instant messaging. Audio-Video Bridging (AVB) is another set of communication standards designed to run on Ethernet and convert the network into a real-time system suitable for audio and video streaming of high-quality infotainment systems [White17] . In addition to the thousands of applications provided by TCP/IP, AVB, and other communication suites to the Ethernet, many protocols implement support functions, such as address resolution, network tracking, and clock synchronization [Arpe21] . All of these are defined in standards defined by organizations such as IEEE and Internet Engineering Task Force (IETF).

All these protocols, suites, applications, and utilities are designed to run on any type of Ethernet, regardless of its underlying implementation. Therefore, the immediate application of Ethernet to cars means that these capabilities can also be applied to cars. In turn, this enables automotive application developers to access many industry standards, widely implemented, and thoroughly combat-tested functions and capabilities. In addition, Ethernet not only provides automotive companies with countless protocols and application options but also enables them to obtain a larger pool of human capital, enabling traditional technology and automotive technology companies to achieve previously impossible synergies. Communication between Electronic Control Units (ECU) in vehicles will no longer be based on technology unique to the industry; they will use the same technology in almost all other industries [Packard21] . This, in turn, will make cooperation between industries easier and open up possibilities for advanced functions and uses. These functions and uses are only speculations so far, and others have yet to be conceived.

2.2 Automotive Ethernet Protocol Architecture

Automotive Ethernet mainly involves OSI's layer 1 and 2 technologies, while automotive Ethernet supports multiple protocols or application forms such as AVB, TCP/IP, Diagnostics over Internet Protocol (DOIP), Scalable Servicei1/4 Oriented MiddlewarE on IP (SOME/IP), etc. Among them, AVB is an extension of traditional Ethernet functions. It enhances the real-time performance of traditional Ethernet audio and video transmission by adding protocols such as precise clock synchronization and bandwidth reservation [Oka21] . It is network audio and video real-time transmission technology with great development potential; SOME/IP specifies the video communication interface requirements for vehicle camera applications, which can be applied to the field of vehicle cameras, and the mode control of driving assistance cameras is realized through Application Programming Interface (API).

As an extension of the AVB protocol, Time-Sensitive Networking introduces time-triggered Ethernet-related technologies, which can efficiently realize the transmission of vehicle control information. In addition, the 1 Gbit rate communication standard in-vehicle Ethernet also supports Power Over Ethernet (POE) function and Energy-Efficient Ethernet (EEE) function [Tuohy16] . The POE function can be a connected terminal while transmitting data on a twisted pair cable.

Automotive Ethernet will not replace all networking needs at the moment but will coexist with classic bus networks for a long time to come.

2.3 Importance of Automotive Ethernet

As cars evolve to semi-autonomous driving and autonomous driving, the communication requirements between the electronic components inside the car will become more frequent, and the amount of data transmission required will also increase exponentially. CAN bus can no longer meet the needs of evolution.

Many car manufacturers and Tier-1 have begun to develop new automotive communication architectures. The topological form consisting of a central gateway and several domain controllers is the current consensus, and this architecture is mainly realized by the automotive Ethernet. Automotive Ethernet only needs a pair of unshielded twisted-pair cables to achieve high-speed grade transmission, which is much faster than CAN [Askarov19] . This kind of wire can be used without an aluminum foil layer and insulating glue layer, and it is lighter than traditional network cables. Conducted radiation and static electricity have also passed relevant international standards. Therefore, the use of automotive Ethernet can greatly increase the transmission bandwidth, and greatly simplify the wiring harness in the vehicle and reduce the weight of the wiring harness.

2.4 Application of Automotive Ethernet in Autonomous Driving System

Autonomous vehicles and Advanced Driver Assistance Systems (ADAS) have put forward more urgent demands for higher bandwidth and lower latency. Automotive Ethernet has become a new backbone for building higher-speed automotive networks. Comprehensive testing of the transmitter, receiver, link segmentation, and high-level protocol functions ensures its successful implementation [Dubbert18].

The main driving forces for innovation in the automotive industry can be divided into three categories: enhancing safety, protecting the environment, and improving convenience through interconnection. To achieve these goals, automakers, auto suppliers, governments, academia, and even companies outside the traditional auto industry (such as wireless chip manufacturers, mobile device manufacturers, and wireless service providers) have all participated in the development of ADAS, connected car technology, and even the ultimate goal-autonomous vehicles.

ADAS and autonomous vehicles need to connect all sensors, cameras, diagnostic tools, communication systems, and central artificial intelligence through high-bandwidth and low-latency networks.

At present, the wire harness ranks third among all auto parts in terms of weight and cost. In the car assembly process, wiring harness installation accounts for 50% of labor costs. Automotive Ethernet is an emerging solution to these challenges. Just as WIFI is the cornerstone of Dedicated Short-Range Communications (DSRC), Ethernet is also a well-known, trustworthy, and widely used solution in the traditional LAN field [Virdis19] . Ethernet has many advantages, such as multi-point connection, wider bandwidth, and low latency, etc., which is very attractive for car manufacturers. However, if it is used in a car, the traditional Ethernet is still too noisy and easily interfered with. To meet the specific needs of the automotive industry, IEEE has formulated new standards and protocols.

2.5 The Challenges of Automotive Ethernet

However, implementing Ethernet in vehicles brings several challenges that are simply not present in current implementations of the Ethernet protocol. With their constrained spaces and prevalence of relatively high-power electronic systems, operation within a vehicle means that networking components and cabling have to withstand elevated temperatures and significant Electro-Static Discharge (ESD) events and Electro-Magnetic Interference (EMI) [Xu21] . And on top of that, there are other issues including vibration, impact, cold, dirt, aggressive fluids, and voltage fluctuations to contend with.

While there are many components available for Ethernet, they are not immediately suitable for the automotive Ethernet protocol. Most components destined for automotive use are subjected to a series of stringent electrical, lifetime, and reliability tests. These tests will qualify components to one of the five grades of AEC-Q100. (Grade 0 is for drivetrain components and is the most stringent [-40AoC to +150AoC] while lower levels for Grades 3 and 4 are closely matched to industrial and commercial levels) [Man20].

3. Fat Tree

The traditional data center uses a multi-level tree structure, which can have a better effect on the client/server model. The tree structure includes single-rooted trees and multi-rooted trees. Multiple root nodes often exist as backup nodes (we use squares to represent switches). The details are shown in Figures 1, 2 below.

Figure 1: Single root topology Figure 2: Multiple roots topology
Figure 1: Single root topology
 Figure 2: Multiple roots topology

The traditional single-root/multi-root topology has the following shortcomings: high cost, the root switch must have enough bandwidth to meet the communication between the lower-level servers; performance bottlenecks cannot meet the large-scale MapReduce and data copying in the data center [Gonzalez21] . To solve the bottleneck problem of the root node of the tree structure, researchers have proposed many available topologies. Divided into switch-centric and server-centric architectures. Among them, Fat-Tree has been widely used in scientific research in recent years.

3.1 Fat-Tree Topology

Fat-Tree is a switch-centric topology. It supports horizontal expansion while expanding the number of paths; and all switches are ordinary devices with the same number of ports, which reduces the cost of network construction. The Fat-Tree structure is divided into three layers: core layer, aggregation layer, and access layer. A k-element Fat-Tree can be summarized into 5 features: Each switch has k ports; The core layer is the top layer, with a total of (k/2)^2 switches; There are a total of k pods, and each pod consists of k switches. Among them, the aggregation layer and the access layer each account for k/2 switches; Each switch at the access layer can accommodate k/2 servers [Alonso15] . Therefore, Fat-Tree has a total of k pods, each pod accommodates k*k/4 servers, and all pods can accommodate k*k*k/ 4 servers; There are k paths between any two pods (limited only to pod-based 3 level Fat Tree). The details are shown in figure 3 below.
Figure 3: Fat-tree topology
Figure 3: Fat-tree topology

One advantage of the fat-tree topology is that all the switches it uses are the same, which allows us to use cheap switches in the entire data center network architecture. Moreover, this architecture has non-blocking characteristics. For any communication mode, there is always a path for their communication bandwidth to reach the network card bandwidth. However, it is still a bit difficult to achieve a 1:1 super-score ratio because it is necessary to prevent the disorder of TCP packets from occurring.

3.2 Routing Design

To make the network reach the maximum bisecting bandwidth, it is necessary to distribute the sent traffic to each core switch as evenly as possible. A routing protocol like OSPF uses the number of hops as a measure of the shortest path. In a fat tree of k pods, there are (k/2)(k/2) between any two servers under unconnected pods. The shortest path, but only one will be selected. The switch will concentrate all traffic on one port, and if the time of the Open Shortest Path First (OSPF) message arrives inconsistent, it will cause the traffic between different pods to be concentrated on individual core switches at certain moments. This will lead to traffic congestion, and the benefits of fat-tree topology cannot be fully utilized [Medhi18].

Use 10.0.0.0/8 to divide all network segments. Describe a network segment according to the following format: switch address in Pod 10.pod.switch.1, pod: [0, k-1], switch: [0,k-1], from left to right, from bottom to top in a single pod. The address of the core switch is 10.k.j.i, where j and i are the positions in the rack, from top to bottom [Ergun21] . The address of the server is assigned according to the address of the switch in the pod, 10.pod.switch.ID, ID is the position of the server in the subnet [2,k/2+1], from left to right. Therefore, each access switch is connected to a /24 subnet, k/2 servers, and k less than 256. Although this is a waste of IP address space, it is relatively simple to build a routing table in this way, and this method supports 4.2M hosts.
To send traffic evenly, we modify the routing table to support two levels of the query. Each instance in the main routing table will have an additional pointer to another table. If an instance does not contain a pointer to the next-level routing table, it ends. More than one instance may point to the next level of the routing table. Since the number of entries in each table will not exceed k/2, the performance is guaranteed.

3.3 Benefits of Fat Tree

(1) The network adopts a horizontal expansion method. By adding pods in the network horizontally, the network can support more servers.
(2) The bisection bandwidth expands with the expansion of the network scale.
(3) Using multiple links to achieve load balancing at the core layer and multiple parallel paths (ECMP) between different pods.
(4) Distributing traffic reasonably within the pod to optimize network load.
(5) Good network fault tolerance, generally no single point of failure.
(6) The network diameter is small, which means that the theoretical network delay is small and the real-time performance is good.
(7) Topological rules are conducive to modular design and expansion.
(8) Commercial switches are used to greatly reduce the cost of network equipment [Solnushkin18].

4 Routing in Fat Trees Protocol

Work on the RIFT protocol officially started in IETF when the RIFT working group charter was approved in February 2018. The charter states: "RIFT protocol addresses the demands of routing in Clos and fat-tree networks via a mixture of both link-state and distance-vector techniques colloquially described as link-state towards the spine and distance vector towards the leaves. RIFT uses this hybrid approach to focus on networks with regular topologies with a high degree of connectivity, a defined directionality, and large scale." [Alonso15].

One of the reasons Clos and fat-tree topologies have become the de facto standard for IP fabrics is the advent of a significant increase in traffic between servers within the data center (East/West) as opposed to traffic leaving or entering the data center (North/South). Spine/leaf variants make it possible for each service's traffic flows to traverse the shortest path, meet capacity needs, and remain highly resilient to failures.

4.1 Topology Information Elements (TIEs)

Topology Information Elements (TIEs) are used to convey a node's connected adjacencies, prefix information, and capabilities (e.g. flood reduction). Remember that RIFT is based on the concept of directionality (north and south) and depending on a node's location in the fabric, will represent itself differently when advertising TIEs in a given direction. Similarly, TIEs are also referred to by the direction in which they are advertised, specifically, North TIEs (N-TIE) or South TIEs (S-TIE) [Alonso15] . Generally, the various types of TIEs carry similar information regardless of the direction they are advertised, with some exceptions. As with LIE messages, the TIEs also support authentication.

4.2 SPF Computation

Like other areas of RIFT, SPF computation is also based upon direction (N-SPF and S-SPF) [Alonso15] . This provides the distinction that allows RIFT to behave as a link-state protocol northbound where nodes at progressively higher levels have a full link-state view of the topology south of it and where nodes at lower levels have a default toward the north. Neither computation can generate looped paths, which enables RIFT to support optional features like bandwidth-based unequal cost load balancing.

4.3 Automatic Disaggregation

The concept of disaggregation has been around for a long time as well. Disaggregation is the opposite of aggregation: it takes a single less specific route (the aggregate route) and splits it up into several more specific routes. The most common use case for disaggregation is traffic engineering. For example, an enterprise that is BGP dual-homed to two service providers may split its address space (described by an aggregate) into two more specific prefixes, and advertise one to each service provider. That way, incoming traffic is split across the two service providers, even if one service provider has a shorter incoming path than the other.

In most existing protocols, disaggregation requires extensive manual configuration; In RIFT, by contrast, disaggregation is fully automatic without the need for any configuration. In most existing protocols, disaggregation is an optional and manual feature that is mainly used for traffic engineering; RIFT, on the other hand, relies on disaggregation as an essential feature to recover from failures [Rijsman19].

There are two types of disaggregation in RIFT. Positive disaggregation, which attracts traffic to the repair path. Similar to existing routing protocols it works by advertising more specific routes, except that RIFT does this automatically instead of as a result of manual configuration. Negative disaggregation repels traffic away from the broken path. This is a completely novel approach that relies on the new concept of a "negative next-hop" [Rijsman19]. These negative next-hops are translated into normal positive next-hops in the data-plane hardware.

4.4 Zero Touch Provisioning

By design any RIFT node in a fabric can operate in Zero Touch Provisioning(ZTP) mode, in other words, it can be connected to the fabric with no initial configuration. Only top-tier nodes need to be configured. Upon connection nodes will fully auto-configure themselves and form adjacencies in a well-defined north/south topology. The derivation of the level of each node happens based on offers received from its neighbors whereas each node tries to attach at the highest possible point in the fabric. ZTP makes DC fabric like RAM banks.

4.5 Junos Implementation of Routing in Fat Tree (RIFT) Protocol

The integration of RIFT protocol into Junos OS has some impact on the route load and memory utilization for common datacenter architectures. This is because the RIFT protocol has the capability of consuming all available cores to improve protocol performance.

The dynamic configuration of RIFT is not fully supported. Configuration changes in the Junos OS CLI might restart the RIFT protocol causing the protocol to re-converge with resulting traffic loss [Kheradpir19].

The RIFT software package is a standalone package and the Juniper implementation of the protocol is executed in modern memory and thread-safe programming language that is designed for optimal utilization of multi-core processor architectures.

The RIFT protocol initializes the associated RIFT processes, and the zero-touch configuration default values are applied through the configuration. It also automatically enables RIFT on all Ethernet interfaces. The system-id is automatically derived from the system MAC address, and the level is automatically determined through the discovery portion of the protocol operation.

After downloading and activating the RIFT software package, we can configure trace options for RIFT. Specify the trace options and proxy-process parameters under the rift statement. And then we can verify the RIFT configuration. The RIFT protocol does not produce core files except in very extreme cases. It reports every failure by extensive logging and sometimes backtraces on exit. The RIFT process provides configurable tracing events that can be collected using trace options configuration.

5. Automotive Ethernet Routing in Fat Trees

The tree structure not only has flexible expansion capabilities, but also has a faster transmission speed, and will have certain advantages in the total amount of wiring. Therefore, the Ethernet fat-tree structure should burst into vigor in the future development process.

The P2P switching network based on in-vehicle Ethernet, the full-duplex working mode, and the conventional CAN-bus mode cannot be applied to the Ethernet system; for the most ring structure, it is not easy to add new nodes, and the single network flexibility is poor, etc. Therefore, the topologies currently used in automotive Ethernet are mainly star topologies, tree topologies, and daisy chain topologies.

5.1 Daisy Chain Topology

This connection method itself can be established for automotive systems. The daisy-chain topology model has slow transmission efficiency in this process, and the signal may not reach the receiving node until it has been forwarded many times. The biggest disadvantage of the daisy chain is that once a node in the data link fails and goes offline, the nodes connected below it cannot communicate with other nodes.

Although the daisy chain topology has many shortcomings, it is not completely undesirable in onboard Ethernet communication. For models with fewer nodes, we can use the daisy chain topology to greatly reduce the number and length of our wiring. At the same time, it can also realize the standardization of the Device side, which can effectively reduce the cost to a certain extent, but once the number of nodes increases and the number of data increases, the shortcomings of the daisy chain will be exposed.

Therefore, the daisy-chain topology will gradually be phased out and should only be used in some low-end models.

5.2 Star Topology

The core of the star topology is to select an Electronic Control Unit (ECU) as the core and integrate the Switch module. Star structure has been used in the CAN network.

The structure of the star topology is more in line with the idea of domain controller integration at this stage. The electronic and electrical system is from decentralized arrangement to the integration idea at this stage, and multiple control modules are gradually integrated into the domain controller, the communication speed is faster, and the communication between multiple ECUs is omitted. The switch only needs to be placed in one of the nodes (usually the domain controller is selected). The other nodes omit the hardware design of the integrated switch, but At the same time, there is still a very important problem that is the design of the number of interfaces of the switch, which also affects how many Sensors can be integrated under the domain controller, which also involves the versatility and standardization of the hardware design of the domain.

The branch length is an important factor that affects the signal stability of the star structure. The smaller the branch length, the better the signal generated, which means that the shorter the branch length of the star structure, the better, but for centralized topology or cause a branch to reach the domain controller across almost the entire captain, so the stability of the signal still has problems.

The star structure can realize the fast communication of P2P, but the possibility of the scattered arrangement of the sensors in the wiring will lead to the increase of the wiring cost. A domain must integrate a switch to complete the exchange of data information of multiple sensors at the same time, which means The number of interfaces will be huge, and the number of interfaces will also lack a unified design standard. After all, the number and layout of the hardware sensors of the ADAS system and the idea of electrical architecture OEM are still in the stage of contending, and there is no consensus.

5.3 Tree topology

The idea of a tree topology is to follow the branches of the trunk, similar to the continuous separation of the branches from the bottom of the tree.

There are many benefits. Easy to expand: Many branches and sub-branches can be extended, so it is easy to add new branches or new nodes to the network (the possibility of expansion is considered at the beginning of the design, and interfaces are reserved); Easy to isolate the fault: If a line or a branch node fails, it mainly affects the local area, so the faulty part can be isolated from the entire system relatively easily (the node is isolated by disconnection); Decrease the data processing load: the data processing is distributed and unfolded instead of relying on a single central processor. In this way, the distributed data processing reduces the data processing load of the central ECU; The tree structure reduces the number and length of wiring to a certain extent, saves costs, and to a certain extent can realize the standardization of the number of controller switch interfaces.

The tree topology and the star topology have the same shortcomings for the central controller The degree of dependence is huge, once the central controller fails, the entire data structure will fail.

The tree structure not only has flexible expansion capabilities, but also has a faster transmission speed, and will have certain advantages in the total amount of wiring. As can be seen from Chapter 3, fat trees have significant advantages in many tree structures. Therefore, the Ethernet fat-tree structure should burst into vigor in the future development process.

6. Conclusion

As it was shown, I surveyed the automotive Ethernet routing in fat trees. First, automotive Ethernet is a new type of local area network technology that connects different automotive electronic devices in the car. And fat-Tree is a switch-centric topology. The RIFT protocol addresses the demands of routing in Clos and Fat-Tree networks via a mixture of both link-state and distance-vector techniques colloquially described as 'link-state towards the spine and distance vector towards the leafs'. Finally, based on its superiority, the Ethernet fat tree structure is bound to occupy an important position in automotive Ethernet.

7. References

  1. [White17] Russ White, Ethan Banks, "Computer Networking Problems and Solutions: An innovative approach to building resilient, modern networks", Addison-Wesley Professional, 2017, 0134762851, 9780134762852.

  2. [Askarov19] Aslan Askarov, Rene Rydhof Hansen, Willard Rafnsson, "Secure IT Systems", Springer Nature, 2019, 303035055X, 9783030350550.

  3. [Denton19] Tom Denton, "Advanced Automotive Fault Diagnosis: Automotive Technology: Vehicle Maintenance and Repair", Routledge, 2020, 1000178382, 9781000178388.

  4. [Kim20] Shiho Kim, Rakesh Shrestha, "Automotive Cyber Security: Introduction, Challenges, and Standardization", Springer Nature, 2020, 9811580537, 9789811580536.

  5. [Dubbert18] Jorg Dubbert, Beate Muller, Gereon Meyer, "Advanced Microsystems for Automotive Applications 2018: Smart Systems for Clean, Safe and Shared Road Vehicles", Springer, 2018, 3319997629, 9783319997629.

  6. [Virdis19] Antonio Virdis, Michael Kirsche, "Recent Advances in Network Simulation: The OMNeT++ Environment and its Ecosystem", Springer, 2019, 3030128423, 9783030128425.

  7. [Oka21] Dennis Kengo Oka, "Building Secure Cars: Assuring the Automotive Software Development Lifecycle", John Wiley & Sons, 2021, 111971074X, 9781119710745.

  8. [Gonzalez21] Jose Rocher-Gonzalez, Jesus Escudero-Sahuquillo, "Towards an efficient combination of adaptive routing and queuing schemes in Fat-Tree topologies", Journal of Parallel and Distributed Computing, Volume 147, Issue 1, January 2021, Pages 46-63, https://www.sciencedirect.com/science/article/abs/pii/S0743731520303385.

  9. [Alonso15] M. Alonso, S. Coll, "Power consumption management in fat-tree interconnection networks", Parallel Computing, Volume 48, Issue 6, October 2015, Pages 59-80, https://www.sciencedirect.com/science/article/abs/pii/S0167819115000599

  10. [Tuohy16] Shane Tuohy, Martin Glavin, "Hybrid testbed for simulating in-vehicle automotive networks", Simulation Modelling Practice and Theory, Volume 66, Issue 7, August 2016, Pages 193-211, https://www.sciencedirect.com/science/article/abs/pii/S1569190X16000022

  11. [Kheradpir19] Shaygan Kheradpir, "RIFT Overview", 2019, https://www.juniper.net/documentation/en_US/junos/topics/topic-map/rift-in-junos.html

  12. [Ergun21] Orhan Ergun, "RIFT - Routing in Fat Trees - Large Scale Datacenter Routing Protocol", 2021i1/4OE https://orhanergun.net/rift-routing-in-fat-trees-large-scale-datacenter-routing-protocol/

  13. [Medhi18] Deep Medhi, Karthik Ramasamy, "Fat Tree Topology", 2018 https://www.sciencedirect.com/topics/computer-science/fat-tree-topology

  14. [Arpe21] Mika Arpe, "Why Automotive Ethernet Is a Strong Choice", 2021 https://www.aptiv.com/en/insights/article/why-automotive-Ethernet-is-a-strong-choice

  15. [Packard21] Keith Packard, "Testing Automotive Ethernet Solutions", 2021i1/4OE https://www.tek.com/automotive/automotive-Ethernet

  16. [Xu21] Bruce Xu, "How to deal with the challenge of vehicle Ethernet debugging", 2021, https://www.automotiveworld.cn/zh-cn/_6/_0/news3.html

  17. [Man20] San Man, "Advantages and challenges of in-vehicle Ethernet technology", 2020, https://www.suncve.com/advantages-and-challenges-of-vehicle-Ethernet-technology/

  18. [Solnushkin18] Konstantin S. Solnushkin, "Fat-Tree Design", 2013, https://clusterdesign.org/fat-trees/

  19. [Rijsman19] Bruno Rijsman, "Automatic disaggregation in the Routing in Fat Trees (RIFT) protocol", 2020, https://hikingandcoding.wordpress.com/2020/07/22/rift-disaggregation/

8. List of Acronyms

LANs - Local Area Networks
RIFT - Routing in Fat Trees
AVB - Audio-Video Bridging
IETF - Internet Engineering Task Force
ECU - Electronic Control Units
DOIP - Diagnostics over Internet Protocol
SOME/IP - Scalable Servicei1/4 Oriented MiddlewarE on IP
API - Application Programming Interface
POE - Power Over Ethernet
EEE - Energy-Efficient Ethernet
ADAS - Advanced Driver Assistance Systems
DSRC - Dedicated Short-Range Communications
ESD - Electro-Static Discharge
EMI - Electro-Magnetic Interference
OSPF - Open Shortest Path First
ECMP - Equal-cost multi-path routing
TIEs - Topology Information Elements
SPF - Sparse Polyhedral Framework
ZTP - Zero Touch Provisioning
ECU - Electronic Control Unit

Last modified on December 15, 2021
This and other papers on recent advances in networking are available online at http://www.cse.wustl.edu/~jain/cse570-21/index.html
Back to Raj Jain's Home Page